Inexpensive connectivity provided by the Internet, along with wireless devices and the emergence of ubiquitous sensors is creating the conditions for a generation of new services based on an ‘always-connected’ feature model. In this model users are always reachable by means of portable wireless appliances without limitation due to time or location. Conversely, users are also always able to reach useful collaborators and information. These capabilities call into question a number of assumptions that underlie traditional prior art call processing models. Many features of prior art call processing models make implicit assumptions about system and user behavior that are used to handle calls to a busy or not-present user. In the ‘always-connected’ feature model, the ‘not-present’ assumption is invalidated.
Traditional models of call processing fall into two distinct categories. The older model utilizes centralized call processing in which a call is created as a single entity in a single place. In such prior art systems, ‘busy’ meant that a telephone set was off-hook and therefore the telephone switch control could not communicate with it.
In the newer Intelligent Network (IN) SS7 (signaling system 7) model, the call results from the cooperation of two distinct entities (call-halves) which cooperate by means of message passing and negotiation over a digital backbone using ISUP protocol. Feature logic is centralized in offices referred to as SCPs (service control points). Features operating in the local offices (SSPs or service signaling points) may have trigger points in their code for referring operation to an SCP to obtain proper behavior.
The distributed call-halve model allows for call processing to be physically distributed. With call state sharing, the assumptions regarding ‘busy’ status have been modified giving rise to features such as ‘call waiting’ and ‘camp on’. A call process separate from the equipment used to make call connection has allowed for communication with the user on an existing call, and user notification of a call queue awaiting his/her attention.
Both of these call-processing models share the characteristic of a centralized definition of features. Indeed, in the instantiation of the Intelligent Network (IN), this was considered to be a primary benefit of the distributed model (i.e. new features can be defined and provisioned centrally in the IN). This has resulted in the benefit of creating a faster time to market for new features and greater stability in the network as features need to be designed only once to run on switching systems purchased from any manufacturer. Network stability has also been enhanced since features have been designed by teams of experienced designers with a view to avoiding ‘bugs’ resulting form interactions of multiple feature designs. Most useful features are specific to and have knowledge of the current user context. IN services therefore have great difficulty with customized and personalized services, which are the services of most utility. As a result the IN and its successor the Advanced Intelligent Network (AIN) have not been able to achieve what had been hoped.
The Internet has created an emphasis on a new set of non-functional requirements that have been difficult to achieve using the above-described existing models of call processing. Centralized feature definitions make it difficult to create customized services tailored to particular enterprises in the public network and to create services personalized to the needs of specific users in enterprise networks, which are hallmarks of Internet applications.
More recently, the SIP and CPL protocols have been developed by IETF to provide user defined call handling (see Sinnreich, H; Johnston, A. B., Internet Communication Using SIP, Wiley, 2001 pp 104-108, and The Internet Draft by Schulzrinne, H.; Rosenberg, J.; SIP Caller Preferences and Callee Capabilities, draft-ietf-sip-callerprefs-05.txt available at: http://www.softarmor.con/sipwg/drafts/draft-ietf-sip-callerprefs-05.txt). In these models call disposition is not controlled by a centralized set of standard features designed in a lab environment by expert developers. Rather, the user specifies a set of personal features that can be tailored to closely match the needs of the user's activities within an enterprise environment. These personal features can be cognizant of the identity of the user's collaborators, the nature of the work being done, the user's calendar and so on.
Within SIP, a user may register several Contact addresses with the proxy server that is serving him/her. The user may specify in the SIP INVITE message the types of connections he/she will accept. This is done by specifying the characteristics of the end point (or User Agent) in the ACCEPT-CONTACT and REJECT-CONTACT headers that the user prefers to either accept or reject, respectively. These headers can specify specific end-points in terms of their URLs as being preferred for acceptance or rejection.
The ability to identify specific end points that are preferred for rejection or acceptance indicates a new level of features that are being enabled by SIP. The caller preferences in SIP may specify specific characteristics of the physical device at the end point, which provides an easily understood application of this protocol to conventional telephony.
However, there is no adequate explanation in the SIP drafts of how conflict between called party and caller preferences may be identified and resolved. The CPL specification [Lennox, J.; Schulzrinne, H.; Call Processing Language Framework and Requirements, IETF RFC2824, http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-06.txt] mentions that certain caller preferences may be ignored in making a decision. However no guidance is given as to whether such a capability is acceptable or even useful. In short the currently specified SIP call handling procedures are inadequate for call handling in realistic call processing situations.
Thus, SIP and CPL do not provide an effective architecture for handling user preferences in the execution of features and especially in the handling of conflicts between preferences. Consequently, doubts have been expressed concerning the scalability and evolvability of such protocols to realistically sized systems using Internet technology.
Accordingly, the inventor has recognized the desirability of extending the IETF model, understanding the features that it enables and developing practical technological solutions to issues in implementation of these features.